<html>
<head>
<title>OGR WCTS Implementation Details</title>
</head>

<body>
<h1>OGR WCTS Implementation Details</h1>

<h2>Methods Implemented</h2>

The OGR WCTS server implements the <b>GetCapabilities</b>, 
<b>IsTransformable</b> and <b>Transform</b> server options (REQUEST= values).
In all operation cases only VERSION 0.1.0 is currently supported.<p>

<h3>GetCapabilities</h3>

The <b>GetCapabilities</b> operation is supported as an XML request 
submitted using the HTTP POST mechanism, or as a key/value pair request
submitted using the HTTP GET mechanism.<p>

The returned capabilities
document is taken from static document provided by the installer, it
is not actually machine generated at all.  In particular the list of
supported coordinate systems is not machine generated.<p>

<h3>IsTransformable</h3>

The <b>IsTransformable</b> operation is supported as an XML request 
submitted using the HTTP POST mechanism, or as a key/value pair request
submitted using the HTTP GET mechanism.<p>

The geometric primite type, 
coverage type, and coverage interpolation method parameters are currently
ignored. <p>

<h3>Transform</h3>

The <b>Transform</b> operation is only supported as an XML request submitted
using the HTTP POST mechanism.<p>

It is apparently legal to submit key/value
pair requests with remotely referred to, or url encoded GML data but there
are no examples of how this would be done so it has not been implemented at
this time.<p>

The transformation sequence (gml:_CoordinateOperation) argument is
unsupported and ignored.<p>

The data argument may be a GML instance document, or a FileURL
referencing a remote document which may be fetched using HTTP GET.  
It may not be a wcts:RemoteOWS element for doing operations against
a remote WFS instance.  How this actually works is not currently well
defined in the WCTS document. <p>

<h3>DescribeTransformation</h3>

The <b>DescribeTransformation</b> operation is not supported by the
server at all at this time.<p>

<h2>Coordinate Systems Supported</h2>

Currently the server supports all EPSG 6.2.2 2D geographic coordinate systems
and projected coordinate systems based on supported projections.<p>

Converting between different datums is
only supported for some coordinate systems for which a single 3 or 7
parameter datum transformation to WGS84 exists in the EPSG database.  Other
datums for which multiple transformations 3 or 7 parameter transformations are
defined, or for which no such transformations are available are not able
to be converted to other datums.  One exception is NAD27 and NAD83.  NAD83 is
considered equivelent to WGS84.  NAD27 is handled specially using grid
shift files for the area of Canada and the United States (either NTv2, NTv1,
or NADCON grid shift information is used depending on the location being 
transformed, and the configuration of the server.<p>

Coordinate systems based on datum that cannot be related to WGS84 can still
be trasformed to other coordinate systems based on the same datum.<P>

<h3>Supported EPSG projections</h3>

<table border>
<th>EPSG Code<th>Name<th>Comments<tr>
<td>9801<td>Lambert Conic Conformal (1SP)
<td><tr><td>9802<td>Lambert Conic Conformal (2SP)
<td><tr><td>9803<td>Lambert Conic Conformal (2SP Belgium) <td>(treated same as 9802)
<tr><td>9804<td>Mercator (1SP)
<td><tr><td>9805<td>Mercator (2SP)
<td><tr><td>9806<td>Cassini-Soldner
<td><tr><td>9807<td>Transverse Mercator
<td><tr><td>9809<td>Oblique Stereographic
<td><tr><td>9810<td>Polar Stereographic
<td><tr><td>9811<td>New Zealand Map Grid
<td><tr><td>9812<td>Hotine Oblique Mercator
<td><tr><td>9813<td>Laborde Oblique Mercator<td>(treated same as 9813)
<tr><td>9815<td>Oblique Mercator
<td><tr><td>9819<td>Krovak Oblique Conic Conformal
<td><tr><td>9820<td>Lambert Azimuthal Equal Area
<td><tr><td>9822<td>Albers Equal Area
<td><tr><td>9823<td>Equidistant Cylindrical
</table>

<h3>Unsupported EPSG Projections</h3>

<table border>
<th>EPSG Code<th>Name<th>Comments<tr>
<td>9808<td>Transverse Mercator (South Orientated)
<td><tr><td>9814<td>Swiss Oblique Cylindrical
<td><tr><td>9816<td>Tunisia Mining Grid
<td><tr><td>9817<td>Lambert Conic Near-Conformal
<td><tr><td>9818<td>American Polyconic
<td><tr><td>9821<td>Lambert Azimuthal Equal Area (Spherical)
<td><tr><td>9824<td>Transverse Mercator Zoned Grid System
<td><tr><td>9825<td>Pseudo Plate Carree
<td><tr><td>9826<td>Lambert Conic Conformal (West Orientated)
<td><tr><td>9827<td>Bonne
<td><tr><td>9828<td>Bonne (South Orientated)
</table>

<h2>User Defined CRSes</h2>

The server has prototype support for coordinate systems described using the
pre-approval 03-010r2 GML CRS schemas.  Details of this implementation are
evolving.  Contact the author for sample requests that work at this time.<p>

<h2>Implementation Strategy</h2>

This section is intended to explain a bit about how the internals of this
server are implemented to better understand likely strengths and weaknesses
of the server.<p>

<ol>
<li> All XML handling is done using the <b>CPL MiniXML</b> parser.  This is
a simple well formed XML parser but it does not treat the whole XML standard
properly.  It is likely to fail dramatically if given files in other than 
8bit codes spaces (ie. UTF-8), and there may well be esoteric XML 
constructions that will not be parsed properly by it. <p>

<li> In order to transform GML geometries, the server walks the &lt;data&gt;
subtree searching for elements recognisable as GML geometries.  The rules
to recognise GML geometries are basically to strip any namespace value off
an element name, and compare to the simple feature GML elements (such as
<b>Polygon, LineString, Point, Box, GeometryCollection, MultiPoint, 
MultiLineString </b> or <b>MultiPolygon</b>.  Problems may be encountered
if non-geometries (marked as being from non-gml names spaces) are incorrectly
identified as being geometries.  Alternate names for geometries (established
by derivation in application schemas) are not supported.<p>

A good aspect of the above approach is that there is no need to understand
the application schema of the gml features passed to the server.<p>

<li> Once recognised GML geometry elements are transformed into OGRGeometry's,
transformed, and converted back into GML to substitute "inplace" in the file.
This process will drop any attributes of the geometries, such as srsName, and
will produce new gml with the gml: namespace prefix regardless of what
namespace may have been in place originally.  Resulting geometries are
converted back to GML using a %.16g C format string preserving double 
precision accuracy, but potentially implying far more precision that is
meaningful depending on the precision of the original points.<p>

<li> When the &lt;FileURL&gt; data item is found, the URL is resolved and
the resulting document is substituted in the place of the original FileURL
in the transformation request.  At this point a special step is done to
try and remove any &lt;?xml&gt; line to avoid confusing the XML/GML parsing.
However, other constructions, such as a DOCTYPE declaration might well foul
things up.<p>

<li> Currently SourceCRS and TargetCRS definitions are supported well supported
by &lt;crsID&gt; as well as a more limited form of user defined coordinate
system.  The user defined coordinate system support is experimental and will
not be further discussed here for now.<p>

Those defined via &lt;crsID&gt; will be inspected for a code, and codeSpace
element.  The codeSpace must be EPSG, and the code will be lookuped up in the
EPSG 6.2.2 .csv files using the OGRSpatialReference:ImportFromEPSG() method.
<p>

<li> Internally all coordinate transformations are accomplished using the
OGRCoordinateTransformation class which in turns converts the coordinate
system definitions into PROJ.4 format, and uses the PROJ.4 pj_transform()
function to transform the points.  This supports reprojection, change of
ellipsoid, change of datum (sometimes), and change of prime meridian.<P>

</ol>

<h2><a name="audit">OGR WCTS Security Audit</a></h2>

A security audit of the OGR WCTS server was completed on 2003/03/29.  In
addition to a careful inspection of the code in the ogrwcts.cpp module, the
following components were also addressed:
<P>

<ol>
<li> libcurl (not checked) - all URLs other than http, https and ftp have
been disabled to avoid issues with less known protocols.
<li> CPLTokenize() support for parsing QUERY_STRING.  (checked)
<li> OGR GML Geometry reading and writing services. (checked)
<li> OGR GML CRS reading and writing services.  (not checked)
<li> cpl_minixml.cpp parsing and serializing services (checked)
<li> cpl_string escaping logic, and stringlist handling (checked)
</ol>

The conclusion is that the <b>ogrwcts</b> is safe for use where
it may potentially be given input by hostile parties as long as user defined
CRS support is disabled.  The user defined CRS code is in flux, so any audit 
will be rapidly outdated.  Disabling user defined CRSes may be accomplished by 
compiling with DISABLE_USER_DEFINED_CRS defined in the GNUmakefile (the 
default).<p>

This security audit was primarily directed to discovering buffer overrun 
issues possible with user input.  Several isses were discovered and corrected
though it isn't clear if they could have been externally utilized to
gain control as each of them related only to buffer overruns within the 
heap (not on the stack).<p>

A review of the overall architectural approach of the server identified only
the issue with use of libcurl to access user supplied URLs.  With this disabled
no vulnerability remains.<p>

The initial security audit was completed by Frank Warmerdam.  An independent
audit is underway by Andrey Kiselev.<p>

<h2>Other Notes</h2>

<ol>
<li> The server does not do any schema validation, but does require input
XML documents to be well formed. <p>

<li> Input SourceCRS and TargetCRS elements must have a <b>crsID</b> 
element with a <b>gml:code</b> that is the EPSG code of the coordinate
system, and a <b>gml:codeSpace</b> that is <b>EPSG</b>.<p>

<li> Version and Service parameters are never checked.<p>

<li> The server handles bounding box (boundedBy properties in GML) specially.
It transforms the box into a polygon, transforms that and then regenerates
a box based on the mimimum bounding box of that polygon.  While better than
just transforming the two corner coordinates of the bounding box, it is not
generally going to produce a minimal bounding box for the features in question
in the target coordinate systems.  In fact, depending on the nature of
the transformation (bowing out of a side for instance) the resulting box
may not even quite contain all the transformed feature.<p>

<li> The current GML geometry handling in OGR does not support tuple 
separators other than " " or ordinate separators other than ",".<p>

</ol>

</body>
</html>
